Communication between application software and a resource, by the production of a Uniform Resource Locator (or URL), is known. (In the singular, application software can be referred to, with increasing levels of brevity, as an: “application program,” “application,” or “App”.) For example, an App for reading emails (such as OUTLOOK from MICROSOFT CORPORATION, Redmond, Wash.) can detect the presence of a URL (or “link”), in an email message, and “activate” that link. Once activated, a user can “go to” the URL (i.e., open the page, at the URL, in a web browser), embedded in an email, simply by selecting the link (e.g., “clicking” the URL with a mouse).
A limitation of this type of activation is that it is “static” (i.e., the particular URL, embedded in an email, is fixed).
A REST (or a REpresentational State Transfer) approach to web services can allow customizable App-to-App communication via URIs. Web services, however, merely provide a more uniform basis for interchange between Apps (typically, business-oriented Apps). The behavior of the App itself is still determined by the coding of the App producer (e.g., MICROSOFT CORPORATION) and is thus “fixed,” from the perspective of an end-user.
It would be desirable to introduce techniques and methods by which to enable user-customization that includes user-customizable production of URLs and, more generally, Uniform Resource Identifiers (URIs). (Uniform Resource Identifier is a term that covers both URLs and Uniform Resource Names). Such capability would provide a greater range of options by which each user can adapt an App's behavior to the user's particular operating environment and needs.